REMARKS 

The Examiner is thanked for the performance of a thorough search. 

By this amendment, Claims 8, 16, 20, 25, 32-35, 37-39, and 42-43 have been amended. 
Amendments to the claims are made for the purpose of improving the readability of the pending 
claims by clarifying the meaning of a local lock manager process by expressly stating the 
implicit definition of a local lock manager process. Claims 1-7, 3 1, 36, and 41 have been 
cancelled as a result of the prior restriction requirement. No claims have been added. Hence, 
Claims 8-30, 32-35, 37-40, and 42-44 are pending in the application. 



REJECTION OF CLAIMS 8-30, 32-35, 37-40, AND 42-44 UNDER 35 U.S.C. § 103(a) 

Claims 8-30, 32-35, 37-40, and 42-44 were rejected under 35 U.S.C. § 103(a) as being 
anticipated by U.S. Patent No. 6,253,236 issued to Troxel et al. ("TroxeF 9 ) in view of U.S. Patent 
No. 6,493,804 issued to Soltis et al. ("Soltis"). It is respectfully submitted that Claims 8-30, 32- 
35, 37-40, and 42-44 are patentable over Troxel and Soltis, either individually or in combination, 
for at least the reasons provided hereinafter. 



CLAIM 8 

Claim 8 features: 

A method of controlling use by concurrent users of a distributed resource on a 
network, wherein use of the resource is limited to a specified maximum number 
of concurrent users, the method comprising the computer-implemented steps of: 
providing a distributed lock manager process comprising a plurality of local 

lock manager processes executing on a corresponding plurality of 

hosts, 

wherein each of the plurality of local lock manager processes may grant a 

lock on the same resource; 
associating a user identification for each user with one host of the plurality of 

hosts; and 
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responding to a request for the resource associated with a first user having a 
first user identification associated with a first host of the plurality of 
hosts by requesting a lock from a first local lock manager process 
executing on the first host, (emphasis added). 

Even if Troxel and Soltis were to be properly combined, at least the above-bolded 
elements of Claim 8 would still not be disclosed, taught, or suggested by Troxel or Soltis, either 
individually or in combination. 

Claim 8 recites a method of controlling use by concurrent users of a distributed resource 
on a network. The resource is limited to a specified maximum number of concurrent users. A 
distributed lock manager process, comprising a plurality of local lock manager processes, 
executes on a corresponding plurality of hosts. Each of the plurality of local lock manager 
processes may grant a lock on the same resource. A user identification for each user is 
associated with one host of the plurality of hosts. A request, associated with a first user having a 
first user identification associated with a first host of the plurality of hosts, for the resource is 
responded to by requesting a lock from a first local lock manager process executing on the first 
host. Advantageously, by responding to requests for resources in this fashion, the number of 
concurrent users of a distributed resource on a network may be controlled in a manner that scales 
to support a large number of clients and avoids a single point of failure. 

Troxel, on the other hand, teaches an approach for enabling a client computer system to 
access data on a mainframe host computer system in a manner that prevents conflicts for data 
stored under different types of file access methods and provides security at a file level and 
recovery from interruption of communication between the host and client computer systems 
(Col. 2, line 40 - Col. 3, line 21). Troxel maintains a concurrent user counter that is incremented 
each time a client computer system logs into the host computer system to enforce limits on the 
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number of concurrent users that can access the host computer system (See concurrent user 
counter 354 at Col. 5, lines 26-30). 

Troxel lacks any suggestion of a distributed lock manager process comprising a 
plurality of local lock manager processes. Instead, the portion of Troxel cited teaches a single, 
centralized component, on the mainframe host computer system, that is responsible for locking 
resources upon receipt of a client request (Col. 1, lines 15-36). Further, Troxel lacks any 
suggestion of associating a user identification for each user with one host of a plurality of hosts. 
Also, the cited portion of Troxel lacks any suggestion of responding to requests for resources as 
claimed. In recognition of the deficiencies of Troxel 's teachings, the Office Action 
acknowledges: 

Troxel does not explicitly teach providing a distributed lock manager process 
comprising a plurality of local lock manager processes executing on a 
corresponding plurality of hosts; associating a user identification for each user 
with one host of the plurality of hosts; and responding to a request for the 
resource associated with a first user having a first user identification associated 
with a first host of the plurality of hosts by requesting a lock from a first local 
lock manager process on the first host. 

Soltis teaches an approach for a global file system that comprises a plurality of clients 
which each may access one or more data storage devices of the global file system (See FIG. 1 ; 
Col. 5, lines 25-45; Col. 10, lines 9-11). The data storage devices may be pooled together into a 
shared disk memory in a Network Storage Pool (NSP) arrangement (Col. 10, lines 19-23). A 
data storage device includes one or more locks that are each associated with the use of a storage 
block of the data storage device. Clients access a particular storage block, of a particular data 
storage device, by requesting a lock associated with the particular storage block from the 
particular storage device (see Abstract; Col. 2, line 45 - Col. 3, line 64). 

In the approach of Soltis, the Network Storage Pool (NSP) provides shared storage 
resources that are substantially equally accessible to each client in the system (Col. 10, lines 33- 
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35). Soltis teaches that each data storage device maintains a set of locks that may be granted to 
any of the clients accessing data blocks of only that data storage device (see FIG. 7; Col. 13, line 
65 - Col. Col. line 32). A particular data storage device of Soltis may only grant locks on the 
data block of that particular data storage device . Thus, Soltis expressly teaches away from a 
distributed lock manager process comprising a plurality of local lock manger processes, 
executing on a corresponding plurality of hosts, that each may grant a lock on the same resource. 

As a result of the fundamental differences between Claim 8 and the approach of Troxel 
and Soltis, numerous features of Claim 8 are not disclosed, taught, or suggested by Troxel or 
Soltis, either individually or in combination. 

For example, Claim 8 recites the feature of "providing a distributed lock manager process 
comprising a plurality of local lock manager processes executing on a corresponding plurality of 
hosts" and "wherein each of the plurality of local lock manager processes may grant a lock on 
the same resource." The single, centralized server of Troxel that is responsible for locking 
resources upon receipt of a client request (Col. 1, lines 15-36) does not suggest a plurality of 
local lock manger processes, executing on a corresponding plurality of hosts, that each may grant 
a lock on the same resource. Indeed, the Office Action acknowledges, "Troxel does not 
explicitly teach providing a distributed lock manager process comprising a plurality of local lock 
manager processes executing on a corresponding plurality of hosts," and instead, relies upon 
Soltis to show these features. 

The portion of Soltis cited to show these features (FIG. 4; Clients 105A-N) merely shows 
a plurality of clients. Clients 105A-N of FIG. 4 request locks on data blocks from the data 
storage devices in the Network Storage Pool (NSP) .400. While each of the data storage devices, 
in the NSP 400, may grant a lock on a data block, a particular data storage device only grants 
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locks to data blocks of that particular data storage device (see FIG. 7; Col. 13, line 65 - Col. Col. 
line 32). Thus, Soltis expressly teaches away from the feature of "wherein each of the plurality 
of local lock manager processes may grant a lock on the same resource." Thus, the above-quoted 
elements are not disclosed, taught, or suggested by Troxel or Soltis, either individually or in 
combination. 

Claim 8 also recites the feature of "associating a user identification for each user with one 
host of the plurality of hosts." Troxel fails to suggest associating a user identification for each 
user with one host of the plurality of hosts. Indeed, the Office Action acknowledges, "Troxel 
does not explicitly teach . . . associating a user identification for each user with one host of the 
plurality of hosts," and instead, relies upon Soltis to show this feature. 

The portion of Soltis cited to show this feature (FIG. 4; Clients 105A-N) merely shows a 
plurality of clients. No explanation is provided by the Office Action as to why clients 105 A-N 
of FIG. 4 show associating a user identification for each user with one host of the plurality of 
hosts. Importantly, the entire disclosure of Soltis lacks any teaching of associating a user 
identification for each user with any host. Further, each host, of the plurality of hosts, to which 
the user identifications are associated, is executing a local lock manager process. As explained 
above, Soltis lacks any teaching of a local lock manger process; consequently, it follows that 
Soltis lacks any teaching of associating a user identification for each user with one host of the 
plurality of hosts that are each executing a local lock manager process. Thus, this element 
cannot be disclosed, taught, or suggested by Troxel or Soltis, either individually or in 
combination. 

Claim 8 also recites the feature of "responding to a request for the resource associated 
with a first user having a first user identification associated with a first host of the plurality of 
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hosts by requesting a lock from a first local lock manager process executing on the first host." 
Troxel fails to suggest responding to a request, as claimed, because, inter alia, Troxel lacks any 
teaching of a local lock manager process. Indeed, the Office Action acknowledges, "'Troxel does 
not explicitly teach . . . responding to a request for the resource associated with a first user having 
a first user identification associated with a first host of the plurality of hosts by requesting a lock 
from a first local lock manager process on the first host," and instead, relies upon Soltis to show 
this feature. 

The portion of Soltis cited to show this feature (Col. 3, lines 41-46) merely states, in toto: 

In summary, device locks provide decentralized control of the shared data storage 
device on which they are located. Clients acquire the locks for excluding other 
clients, thereby maintaining data consistency, or for shared use by multiple 
clients. The device locks allow use of a serverless distributed architecture global 
file system (GFS). 

While the cited portion of Soltis states that clients may acquire locks for shared use by 
multiple clients, Soltis teaches that a particular data storage device may only grant locks for data 
blocks of the particular data storage device (see FIG. 7; Col. 13, line 65 - Col. Col. line 32). 
Thus, when a data storage device receives a request for a resource that involves a lock, rather 
than requesting a lock from a local lock manager process executing on a host associated with the 
user identification that is associated with the requesting user, the data storage device processes 
the request without communicating with a local lock manager process. Indeed, as explained 
above, Soltis lacks any suggestion of a user identification that associates users with hosts or a 
local lock manager process that may grant a lock on the resource as another local lock manager 
process. As a result, this element is not disclosed, taught, or suggested by Solits. 

As at least one element of Claim 8 is not disclosed, taught, or suggested by Troxel or 
Soltis, either individually or in combination, it is respectfully submitted that Claim 8 is 
patentable over the cited art and is in condition for allowance. 
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Troxel and Soltis also have not been properly combined, and as a result, the rejection 
under 35 U.S.C. § 103(a) may not be maintained. The Office Action states that it would have 
been obvious to "combine the teachings of Troxel with the teaching of Soltis in order to provide 
decentralized control of shared data, therefore maintaining data consistency (col. 3, lines 41- 
45)," but nothing in either Troxel or Soltis that teaches or suggests combining their respective 
teachings. 

As stated in the Federal Circuit decision In re Dembiczak, 50 USPQ.2d 1617 
(Fed. Cir. 1999), (citing Gore v. Garlock, 220 USPQ 303, 313 (Fed. Cir. 1983)), "it is very easy 
to fall victim to the insidious effect of the hindsight syndrome where that which only the inventor 
taught is used against its teacher." Id. The Federal Circuit stated in Dembiczak "that the best 
defense against subtle but powerful attraction of a hindsight-based obviousness analysis is 
rigorous application of the requirement for a showing of the teaching or suggestion to combine 
prior art references." Id. Thus, the Federal Circuit explains that a proper obviousness analysis 
requires "particular factual findings regarding the locus of the suggestion, teaching, or 
motivation to combine prior art references." Id. (emphasis added). 

In particular, the Federal Circuit states: 

"We have noted that evidence of a suggestion, teaching, or motivation to 
combine may flow from the prior art references themselves, the knowledge of 
one of ordinary skill in the art, or, in some cases, from the nature of the 
problem to be solved. . .although 'the suggestion more often comes from the 
teachings of the pertinent references' . . .The range of sources available, 
however, does not diminish the requirement for actual evidence. That is, the 
showing must be clear and particular. . .Broad conclusory statements 
regarding the teaching of multiple references, standing alone, are not 
'evidence.'" Id. (emphasis added; internal citations omitted). 

Neither Troxel or Soltis show any suggestion, teaching, or motivation to combine their 
teachings, nor does the Office Action provide a "clear and particular" showing of the suggestion, 
teaching, or motivation to combine their teachings. The portion of Soltis cited to show such a 
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motivation (Col. 3, lines 41-45) does not provide any motivation for combination with Troxel, 
but instead, states that a particular device, to control and ensure the consistency of data at that 
particular device, may use device locks. Nothing in this portion suggests any motivation for 
combining the Soltis with Troxel. In fact, the only motivation provided in the Office Action is 
the hindsight observation that by combining features of those references, one may achieve the 
benefits achieved from the invention as described and claimed in the application. Such a 
hindsight observation is not consistent with the Federal Circuit's requirement for "particular 
factual findings." 



CLAIM 16 

Claim 16 features: 

A method of controlling concurrent users of a distributed resource on a network, 
the resource limited to a maximum number of concurrent users, the method 
comprising the computer-implemented steps of: 

receiving a request for the distributed resource from a client process for a user 

having a user identification; 
determining a home location associated with the user identification, the home 

location indicating a unique host among a plurality of hosts that 

execute a corresponding plurality of local lock manager processes of a 

distributed lock manager process, 
wherein each of the plurality of local lock manager processes may grant a 

lock on the same resource; 
sending a request for a lock object for the distributed resource to a first local 

lock manager process of the distributed lock manager process, the 

request including the home location; 
receiving the lock object for the distributed resource from a second local lock 

manager process executing on the unique host, if a number of 

outstanding locks granted by the second local lock manager process is 

less than a value of a local resource maximum defined for the second 

local lock manager process; and 
providing access to the resource to the first client only in response to receiving the 

lock object, (emphasis added). 
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As explained above, Troxel and Soltis have not been properly combined; as a result, the 
rejection of Claim 16 under 35 U.S.C. § 103(a) cannot be properly maintained based on the 
improper combination of Troxel and Soltis. However, even if Troxel and Soltis were to be 
properly combined, at least the above-bolded elements of Claim 16 would still not disclosed, 
taught, or suggested by Troxel or Soltis, either individually or in combination. 

As explained above with respect to Claim 16, Troxel and Soltis both fail to teach the 
concept of a local lock manager process. Consequently, Troxel and Soltis, either individually or 
in combination, fail to show numerous features of Claim 16 featuring a local lock manager 
process, such as: 

"determining a home location associated with the user identification, the home 

location indicating a unique host among a plurality of hosts that execute a 
corresponding plurality of local lock manager processes of a distributed 
lock manager process, 

wherein each of the plurality of local lock manager processes may grant a lock on 
the same resource; 

sending a request for a lock object for the distributed resource to a first local lock 
manager process of the distributed lock manager process, the request 
including the home location; 

receiving the lock object for the distributed resource from a second local lock 

manager process executing on the unique host, if a number of outstanding 
locks granted by the second local lock manager process is less than a value 
of a local resource maximum defined for the second local lock manager 
process" 

Additionally, Troxel fails to suggest a determining a home location associated with a user 
identification, where the home location indicates a unique host among a plurality of hosts that 
execute a corresponding plurality of local lock manager processes of a distributed lock manager 
process. Indeed, the Office Action acknowledges that Troxel, "fails to teach the home location 
indicating a unique host among a plurality of hosts that execute a corresponding plurality of local 
lock manager processes of a distributed lock manager process," and instead, relies upon Soltis to 
show this feature. 
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However, the portion of Soltis cited to show this element merely shows clients 105A-N 
of FIG. 4 of Soltis. This teaching does not cure the deficiencies of Troxel 's teaching because 
there is no suggestion of (a) a home location associated with a user identification, (b) anything 
indicating a unique host amount a plurality of hosts, or (c) a plurality of local lock manager 
processes of a distributed lock manager process. Consequently, this element cannot be disclosed, 
taught, or suggested for this reason as well. 

As at least one element of Claim 16 is not disclosed, taught, or suggested by Troxel or 
Soltis, either individually or in combination, it is respectfully submitted that Claim 16 is 
patentable over the cited art and is in condition for allowance. 



CLAIM 20 

As explained above, Troxel and Soltis have not been properly combined; as a result, the 
rejection of Claim 20 under 35 U.S.C. § 103(a) cannot be properly maintained based on the 
improper combination of Troxel and Soltis. 

The Office Action has rejected Claim 20 under the same rationale as Claim 16. 

However, Independent Claim 20 features elements that are not recited in Claim 16 . For example, 

Claim 20 features the elements of: 

A method of controlling concurrent users of a distributed resource on a network, 
the distributed resource limited to a maximum number of concurrent users, the 
method comprising the steps of: 

receiving at a first local lock manager process of a distributed lock manager 
process a request for a lock object for the distributed resource from a 
resource server, wherein the request includes data indicating a 
particular user home location; 

determining whether a second local lock manager process of the distributed 
lock manager process is associated with the particular user home 
location, and if so, requesting the lock object from the second local 
lock manager process 
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wherein the first local lock manager process may grant a lock on the same 
resource as the second local lock manager process, (emphasis added) 

The above-bolded elements of Claim 20 are not recited in Claim 16. As a result, there 
are no reasons on the record as to why the above-bolded elements of Claim 20 are not patentable 
over the cited art . 

Troxel and Soltis, either individually or in combination, fail to suggest a first local lock 
manager process that may grant a lock on the same resource as the second local lock manager. 
Further, Troxel and Soltis, either individually or in combination, fail to suggest a request that 
includes data indicating a particular user home location. 

As a result, for at least the above reasons, the Applicant respectfully submits that Claim 
20 is patentable over the cited art and is in condition for allowance. 



CLAIM 25 

Claim 25 features: 

A method of distributing a resource on a network, the resource limited to a 
maximum number of concurrent users, the method comprising the steps of: 
providing a distributed lock manager process comprising a plurality of local 

lock manager processes executing on a corresponding plurality of 

hosts, 

wherein each of the plurality of local lock manager processes may grant a 
lock on the same resource; 

generating a value for a local resource maximum number of users stored on 
each host of the plurality of hosts such that a summation over the 
plurality of hosts of the value for the local resource maximum yields 
an aggregate value that does not exceed the maximum number of 
concurrent users; 

determining whether to increase a first value in a first resource maximum stored 

on a first host of the plurality of hosts; and 
if it is determined to increase the first resource maximum, then 

decreasing by a particular amount a second value in a second resource 
maximum stored on a second host of the plurality of hosts, and 
increasing by the particular amount the first value in the first resource 
maximum stored on the first host, 
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wherein each local lock manager process is configured to grant a lock 
for the resource if the number of outstanding locks granted by 
the local lock manager process is less than a value of the local 
resource maximum stored on the corresponding host. 

(emphasis added). 

As explained above, Troxel and Soltis have not been properly combined; as a result, the 
rejection of Claim 25 under 35 U.S.C. § 103(a) cannot be properly maintained based on the 
improper combination of Troxel and Soltis. However, even if Troxel and Soltis were to be 
properly combined, at least the above-bolded elements of Claim 25 would still not disclosed, 
taught, or suggested by Troxel or Soltis, either individually or in combination. 

As explained above, neither Troxel nor Soltis suggest a local lock manager process as 
claimed. Consequently, for at least the above reasons, neither Troxel nor Soltis show, inter alia, 
the elements of: 

"providing a distributed lock manager process comprising a plurality of 
local lock manager processes executing on a corresponding 
plurality of hosts, 

wherein each of the plurality of local lock manager processes may grant a 
lock on the same resource, 

wherein each local lock manager process is configured to grant a lock for 
the resource if the number of outstanding locks granted by the 
local lock manager process is less than a value of the local resource 
maximum stored on the corresponding host" 

Troxel is cited to show the element of "generating a value for a local resource maximum 
number of users stored on each host of the plurality of hosts such that a summation over the 
plurality of hosts of the value for the local resource maximum yields an aggregate value that does 
not exceed the maximum number of concurrent users." However, the portion of Troxel cited 
(Abstract; FIG. 4D; Col. 1, lines 15-36) lack any suggestion any value, for a local resource 
maximum number of users, that is stored on each host of a plurality of hosts such that a 
summation over the plurality of hosts of the value yields an aggregate value that does not exceed 
the maximum number of concurrent users. Instead, the portion of Troxel cited shows a single, 
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centralized server that provides a locking mechanism. Thus, arguendo, while such a single, 
centralized server might store a value for a maximum number of users that may access a 
particular resource (although the cited portion of Troxel does not states this), such a single, 
centralized server cannot store "a value for a local resource maximum number of users stored on 
each host of the plurality of hosts such that a summation over the plurality of hosts of the value 
for the local resource maximum yields an aggregate value that does not exceed the maximum 
number of concurrent users" since a single, centralized server is not analogous to a plurality of 
hosts. Consequently, this element is not disclosed, taught, or suggested by Troxel. 

As at least one element of Claim 25 is not disclosed, taught, or suggested by Troxel or 
Soltis 9 either individually or in combination, it is respectfully submitted that Claim 25 is 
patentable over the cited art and is in condition for allowance. 

CLAIMS 9-15, 17-19, 21-24, 26-30, 32-35, 37-40, AND 42-44 
Claims 32-35 are computer-readable medium claims that each feature limitations similar 
to those recited in method Claims 8, 16, 20, and 25. Consequently, it is respectfully submitted 
that Claims 32-35 are patentable over the cited art and are in condition for allowance for at least 
the reasons given above with respect to Claims 8, 16, 20, and 25 respectively. 

Claims 37-40 are apparatus claims in accordance with 35 U.S.C. § 1 12, sixth paragraph, 
which each feature limitations similar to those recited in method Claims 8, 16, 20, and 25. 
Consequently, it is respectfully submitted that Claims 37-40 are patentable over the cited art and 
are in condition for allowance for at least the reasons given above with respect to Claims 8, 16, 
20, and 25 respectively. 
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Claims 42-44 are apparatus claims that each feature limitations similar to those recited in 
method Claims 8, 16, and 25. Consequently, it is respectfully submitted that Claims 42-44 are 
patentable over the cited art and are in condition for allowance for at least the reasons given 
above with respect to Claims 8, 16, and 25 respectively. 

Claims 9-15, 17-19, 21-24, and 26-30 are dependent claims, each of which depends 
(directly or indirectly) on one of the claims discussed above. Each of Claims 9-15, 17-19, 21-24, 
and 26-30 is therefore allowable for the reasons given above for the claim on which it depends. 
In addition, each of Claims 9-15, 17-19, 21-24, and 26-30 introduces one or more additional 
limitations that independently render it patentable. However, due to the fundamental differences 
already identified, to expedite the positive resolution of this case a separate discussion of those 
limitations is not included at this time, although the Applicant reserves the right to further point 
out the differences between the cited art and the novel features recited in the dependent claims. 
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CONCLUSION 

It is respectfully submitted that all of the pending claims are in condition for allowance 
and the issuance of a notice of allowance is respectfully requested. If there are any additional 
charges, please charge them to Deposit Account No. 50-1302. 

The Examiner is invited to contact the undersigned by telephone if the Examiner believes 
that such contact would be helpful in furthering the prosecution of this application. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 



2055 Gateway Place, Suite 550 
San Jose, C A 95110 
(408)414-1225 
Facsimile: (408)414-1076 
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